Nevermind the checks in the config - just did some testing, will change back.

Okay, looks like there's a bit more work left to-do than I expected :-)

Will have another go at the schema validator today, see if I can get that running and if it fixes the issues. Then try to make the code more robust.

Okay it's now working and not failing for false-strings, memory objects and the like.
Will still have to do some cleaning and double-checking though ...

Yes, the skip function should be easy to implement. And yes it's probably nicer to omit those warnings and only show in case something goes wrong!

I will also have to test this a bit more with more fancy pipelines before making a PR over at tools.
And I ended up copying the params anyway because that's easier to filter than a JSON object - but I'm not entirely trusting this copy yet (fear that it might be too shallow) - so I will have to do some more testing there as well.

Alright did some more testing and all the different schema types seem to validate correctly.
The only thing I might add as well is to check unrecognised parameters for similarity with correct params, as you suggested Phil.

Apart from that it should be fine - let me know if you can still find some bugs :-)

If we were to add this in the current version to tools, we would need to:

• add the groovy function to lib
• adjust the main.nf template to include the validation code
• add the validate_schema param to nextflow.config by default
• extend the nf-core download utility to get those java dependencies
• add patterns to the memory and duration objects so that they can be properly validated

I was also wondering whether we should put the complete function in Schema.groovy? I made a separate script mainly because it was easier to test this way .

• extend the nf-core download utility to get those java dependencies

How would this work?

It should be enough to just run this once:

grape install org.json json [20201115]
grape install org.everit.json org.everit.json.schema [1.5.1]

That installs all necessary dependencies.
Only thing I just realized now, and that might be a problem, is that grape is not installed if you just install nextflow, it comes with the complete groovy installation ... so that might be an issue, will have a closer look

There's also the NXF_GRAB nextflow env variable, which: "Provides extra runtime dependencies downloaded from a Maven repository service."
So it might also be possible to use that for downloading the dependencies somehow.

Well I will do some testing today. If the command line version doesn't work, then a dirty workaround would be to fire up a small NF script which get's the dependencies via @grab .
Really not quite sure how all of this groovy magic is working :D

Okay now I just saw your comments - continuing in the main thread so it's easier to follow.

Okay then that's a problem with downloading... also my last two comments won't help solving then I think. Not quite sure about the NXF_GRAB but probably that won't help either.

I'm pretty sure it pulls some other libraries unfortunately :/
Will try anyway. Way to go would then be to download the jars in case we need them and put them to lib/, I guess

Considering that this parameter checking is a nice, but not a required functionality, I'm wondering whether we absolutely need this for offline use? Could just add a warning that "parameter validation not available when running offline" or something like that. Just in case we need to add too much bulk in order to get it to work.

Alright I'll try to play around with the JARs now :)

As I feared json-schema needs other dependencies, and it fails because of that (otherwise imports seem to be fine).

Not sure if that can be resolved, just putting these dependencies into lib/ as well doesn't seem to work. Will keep looking for ways to solve this.

Okay turns out we really need those dependencies somehow because groovy fails even if we don't execute the code. It still checks for the libraries.

When specifying the dependencies with NXF_GRAB, nextflow dowloads them to .nextflow/capsule/deps and running the pipeline offline works. It's similar to specifying them with @Grab inside the groovy script, which saves it to .groovy/grapes

When NXF_GRAB is defined, executing any nextflow command will download the dependencies to .nextflow/capsule/deps.

Currently the only way I see to make this work is to download the dependencies in one of the two ways mentioned above when running nf-core download, shipping it with the downloaded archive, and then telling the user to move the dependencies to the .nextflow/capsules/deps directory.
That's not nice because it's extra work for the user but it's the only way I can see right now, considering that putting the JAR files to lib didn't work.

Think I will post this to slack in the hope for more ideas :)